I was recently asked to help someone understand the OpenSource movement, and the effects it might have on companies such as Oracle or SAP. I talked a bit that these companies can benefit from being independant of big vendors like Microsoft, while still not having to do everything themselves. But also on how opensource alternatives to their products will threaten their business in the long run and force them to be more innovative and constantly improve their product. I then talked about the 'viral' aspects in OpenSource; not about that GPL licensing bullshit (just read the licenses of stuff you want to use, and don't use them if you don't like the license...; this virality is highly overrated due to Microsofts FUD), but a very different kind of virality: Let's say you are supposed to evaluate different CMS solutions. So you install one or another that sounds promising. Most likely you'll install an opensource database like MySQL or Postgresql. And when you've decided upon a solution, you are quite likely to go with this database, and say to yourself: "if MySQL doesn't scale up well enough for our needs, we can still but an Oracle license". This would be probably different if you had had installed Oracle in the first place. Say a demo or so. But the demo versions of the CMS you tried already made you comfortable in using MySQL; it's easy to install (most likely included with your system anyway), and it just works. But would you have tried a CMS in first place that actuall required you to setup Oracle? Anyway, this "social" virality brought me to another point: developers and administrators. When you see numbers on the market share of Microsoft, they're still huge. Some 95% of users are using Microsoft as their primary operation system (I'm discounting the fact that a huge share of DSL modems here is running Linux, so actually many people are Linux users, and I'm also discounting the use of www.google.com, which would make 99.9% of people Linux users...). But these are the average users. But they aren't on their own. The software choice of the "average user" is influenced by a couple of factors, including:

• if anything goes wrong, whom can I call for help?
• company (administrative, security) policies
• word of mouth and (software) recommendations

But if you look at the computer geeks around you, what are they using? A huge share of the people I know are using Linux. Not everyone is using Linux as their main desktop system, but many are. Others are using Linux just for their development stuff, some only on servers. It doesn't really matter, Linux is huge with the geeks. When I look at the sofware my mom has installed on her Windows system (which also dual-boots Linux, and interestingly is the primary choice for watching a movie - Windows doesn't playback sound with some videos...): half of it is opensource. There is OpenOffice.org, Gimp, Gaim, Firefox, Thunderbird, Inkscape, LyX, Mplayer and a couple others. He favourite game? PySol. My dad already has switched to Linux as his main operating system. So why did they switch to so much opensource software? Because it's what I recommended them, and where I can help them. My mom needed a software to record something for her blog (yes, she's "podcasting" now) - of course I recommended her an opensource application, audacity. My mom is giving private lessons in math and physics; she's very successful at that. When one of her students got herself a laptop, she of course was given all kinds of (opensource!) software. For her highschool thesis she needed a vector graphics program - she ended up with inkscape. Now if my parents have some problem with Windows, who are they going to ask? I didn't manage to solve the video playback issues, my mom by herself switched to Linux for watching movies. It didn't work with Windows, I couldn't help her - she switched to something where she knews she'd get more support (and where the problem by chance didn't occur). Now let's have a look at the university. Our computer pool for the students is all Linux. There are a few windows systems for legacy purposes, I never found out if they are accessible to regular students; I only know they're supposed to exist. When doing some assignment, you're very often required to use some opensource software. For a thesis, you'll very likely be building upon some opensource system. The mathematics institute is still on solaris, but recently Gnome was installed there. Physics and electrical engineering also have mostly Linux systems, I've heard. For software development, it's pretty much a "develop on Linux, run anywhere", whereas Windows-only developers usually need to port their applications (or trust on Wine being able to run them good enough on Linux). So more and more people start developing on Linux, and get to love it's great development environment (after all, Linux was pretty much completely done by software developers...). And that is how Microsoft might already have lost the desktop war: developers, technical students and administrators (who usually also love their Linux boxes). They're only a small share of the userbase, but they're influential. In fact, other users rely on them being able to eventually fix their systems for them. But since these are using Windows much less already, they will be less capable of assisting others with Windows. They'll be putting Linux systems everywhere, and keep on encouraging them to make the switch. Of course it will still take some years, but you can expect more and more companies (and cities) to switch over, like the city of Munich. Windows support staff on the other hand might even become more expensive. I don't know of any numbers on the MCSE programme (Minesweeper Consultant, Solitaire Expert) - does anyone have numbers on "graduates" for that?

Chris Samual writes a good summary of Peter Gutmann's analysis of the cost of Vista (in terms of DRM).

The following paragraph in the article however seemed more interesting to me:
Once a weakness is found in a particular driver or device, that driver will have its signature revoked by Microsoft, which means that it will cease to function (details on this are a bit vague here, presumably some minimum functionality like generic 640x480 VGA support will still be available in order for the system to boot). This means that a report of a compromise of a particular driver or device will cause all support for that device worldwide to be turned off until a fix can be found.

Now just imagine that you want to cause widespread disruption - a DOS (Denial Of Service) attack against Windows users. What better option than to cause most of them to have hardware that's not acceptable to the OS? I expect that there will be many instances of security holes in drivers and hardware being concealed by MS because they can't afford the PR problems resulting from making millions of machines cease functioning. But just imagine that someone finds hardware vulnerabilities in a couple of common graphics drivers or pieces of hardware and publicly releases exploits shortly before a major holiday. If it's public enough (EG posted to a few mailing lists and faxed to some major newspapers) then MS would be forced to invoke the DRM measures or lose face in a significant way. Just imagine the results of stopping 1/3 of machines working just before Christmas!

Of course after the first few incidents people will learn. It shouldn't be difficult to configure a firewall to prevent all access to MS servers so that they can't revoke access, after all our PCs are important enough to us that we don't want some jerk in Redmond just turning them off. Of course disabling connections to MS would also disable security updates - but we all know that usability is more important than security to the vast majority of users (witness the number of people who happily keep using a machine that they know to be infected with a virus or trojan).

If this happens and firewalling MS servers becomes a common action, I wonder if MS will attempt the typical malware techniques of using servers in other countries with random port numbers to get past firewalls. Maybe Windows updates could be spread virally between PCs, this method would allow infecting machines that aren't connected to the net via laptops.

Finally, I recommend that people who are interested in such things read Eastern Standard Tribe by Cory Doctorow, he has some interesting ideas about people DOSing corporations that they work for which seem surprisingly similar to what MS is doing to itself. I'll post about my own observations of corporations DOSing themselves in the near future.

This is what happens when you use fancy XGl/aiglx/whatever eye-candy too much. It will infect (remember the viral properties of opensource software) your body, and you'll start randomly flipping over, too.

Ding ding. (Round 1 - for those who missed it) Kidding aside, remember that I like and respect both of them. Libraries In the first article, I mentioned that Ruby has a lot of momentum, which is a pleasant change from Tcl's relative 'uncoolness' amongst the Web 2.0/O'Reilly/"next big thing" crowd. That said, there are still places where that momentum hasn't taken it. I set about writing some code that I'd wanted to play with that involves sending some email. Something that's very easy in Tcl: http://tcllib.sourceforge.net/doc/smtp.html (towards the end of thepage). Python seems to have a pretty complete email system too, for that matter: http://docs.python.org/lib/module-email.html. So it appears that, based on a sample of one attempted task (how's that for statistics?), that Ruby is still lacking a few things in its standard distribution. Note that this functionality is available elsewhere (TMail, to cite one), but email is ubiquitous enough that it ought to be in the standard library. Command line swiss-army knife While Ruby's OO system gives it a head start when you need to create a larger system with distinct parts, it can still be used as a quick'n'dirty scripting language for quick one-off jobs. From the man page:

% cat /tmp/junk
matz
% ruby -p -i.bak -e  $_.upcase!  /tmp/junk
% cat /tmp/junk
MATZ

Very handy. Tcl's command-based syntax just isn't quite as quick for those sorts of operations, so Ruby wins hands down here. I've suggested that the Tcl folks distribute a second program that takes a lot of the Perl-style command line arguments for this sort of work, but the idea doesn't seem to be of much interest. C API's On another tack completely, one of the things that originally drew me to Tcl was its very, very nice C API. It's documentation is clear, and thorough, and the API itself lets you get involved in pretty much any aspect of the language that you want. This makes sense, because when Tcl was originally created by Dr. Ousterhout in the late '80ies, the idea was to create a scripting language as a C library that would be loaded into other programs. The language has always been faithful to its heritage, and to this day I find it lots of fun to merge Tcl with C code. I have to admit that I don't know the Ruby API all that well, but what I have looked up looks pretty nice. To a certain degree, it's comparing apples and oranges, because Ruby requires you to deal with the very object oriented nature of the language, whereas Tcl is a lot more direct. The Programming Ruby book's coverage of the subject also leads me to believe that Tcl really gives you access to more stuff (interpreters, channels, events, and many other parts of the system). Ruby seems to take an approach that might best be described as letting you write Ruby in C - meaning that you create Ruby objects, use their methods, get their values, and so on, but you're still really dealing with Ruby. This has a certain elegance, but sometimes it's necessary to muck about with things at a lower level. I don't know how it works out in practice, but Ruby has a bit more infrastructure in place for actually building extensions once you've created them. Tcl has "tea", which is a set of m4 macros, but anyone can tell you that the auto tools are not much fun to work with (going to the dentist is more fun) - anything that keeps me away from them is welcome. Garbage collection One of the more interesting aspects of the different approaches to C interoperability is the fact that Tcl uses a simple, robust, straightforward reference counting system to keep track of, and throw away resources that are no longer used. Ruby has a mark and sweep garbage collector, which is probably more sophisticated, but also more complicated, and requires a bit more support from the programmer initially. The benefit is that once things are set up, they require less keeping track of, because you hand off memory management to the computer. From the end user's point of view, Ruby wins here, but if you happen to be writing a C extension, I could see it being more difficult to write and debug to this API, although Tcl has its own warts, one of the worst of which is the fact that Tcl values must be convertible back and forth to strings, so that for things like a file handle that can't really survive the round trip, because it's just a pointer, you use a hash table and some sort of string to hold onto the object:

 "file1" -> int fd1
 "file2" -> int fd2

which makes it impossible to GC these values. I suspect that both approaches have their merits - Ruby's is more elegant, but Tcl's is simple and rugged. Licensing Bouncing back to something completely non-technical, Ruby's licensing is either the GPL, or their own license. If I understand things correctly, you can get around the GPL's "viral nature" by simply renaming things, if you have a need to include Ruby in a proprietary product:

1. You may distribute the software in object code or executable form, provided that you do at least ONE of the following: a) distribute the executables and library files of the software, together with instructions (in the manual page or equivalent) on where to get the original distribution. b) accompany the distribution with the machine-readable source of the software. c) give non-standard executables non-standard names, with instructions on where to get the original software distribution. d) make other distribution arrangements with the author.

So it seems that you're ok if you just call it something else. However, the license goes on to talk about several other files in the core distribution:

1. You may modify and include the part of the software into any other software (possibly commercial). But some files in the distribution are not written by the author, so that they are not under this terms. They are gc.c(partly), utils.c(partly), regex.[ch], fnmatch.[ch], glob.c, st.[ch] and some files under the ./missing directory. See each file for the copying condition.

Looking through the LEGAL file in the distribution shows that there are files distributed under other terms. Of course, they're all free software, but some are LGPL, some BSD, and a few others for good measure. Tcl's licensing, on the contrary, requires very little understanding. The language was developed at the University of California, Berkeley, and the license remains BSD. This goes for many of the libraries and extensions as well. If you need to embed a language in your proprietary system, Tcl and its libraries present no problems whatsoever. Of course, I prefer to work with open source code and communities, but that's not possible 100% of the time, so it's always nice to know things are free and clear, should that need arise. Internationalization This is something the Ruby folks know they need to fix, and are working on, so it's not worth dwelling on it much, but it is a proud point for the Tcl community. Tcl has had very nice i18n setup for many years, at this point - since the 8.0 release. It's built into the language, so that everything works with it. You have commands to set encodings of IO channels, and even munge strings. Tcl wins here - no contest. As I continue exploring Ruby, I think I'll find more stuff to compare with Tcl, so we won't ring the final bell just yet.

We live out in the country and both have allergies. But we both enjoy cats, and we've had one almost continuously since we moved to Kansas. Our cats are outdoor cats. They always seem to enjoy roaming around the yard so much, it's hard for me to imagine keeping a cat indoors. I know plenty of cats are happy there, but it's not for us -- especially since we're both allergic to cats. We've had Tux for about 2 of his 3 years. Tux is not a cat with your typical cat personality. Tux loves attention and loves to be petted. But he is also afraid of just about everything. Here are a few things that have caused Tux to be scared over the years. I promise I am not making any of these up:

• His own shadow
• Rustling leaves
• Terah getting a new hairstyle
• People carrying grocery bags
• Grocery bags sitting perfectly still on the ground
• Other cats, even if smaller than him
• The wind
• Terah wearing a dress
• Snow
• The lack of snow (it melted since he was outside the day before)

Tux's favorite activity is hunting. We often joke that if he can work up the courage to not be afraid of his prey, he'll do well. And he does -- even catches rabbits sometimes. Here's Tux starting his morning patrol: We always knew he had a routine, but only found out last month that our neighbors would see him coming up the hedge row, just poking his head around to look at their yard, and then head back to us -- each morning. He also jumps down in our window well, and we can see the shadow of a tail wisping by the basement windows, each afternoon. Tux gets half of our 4-car garage/shed at night. He enjoys going in there -- it's safe. (We put him in to keep him safe from the coyotes.) But he has a routine that Terah and I must follow precisely if he is to go in. First, we're supposed to go outside and look for him. Then, no matter where he is -- even if he's right by the garage door -- we have to walk to the house with him, then back to the garage. He doesn't like to be carried, but likes to walk just ahead of us, ears pointed backwards to make sure we're following properly. Then he will stop just outside the garage door and wait for us to step over him and go in first (to make sure it's safe). Then he'll go in. Tux has become quite the popular cat. Terah set him up with a very funny blog on Catster.com, and he was a featured cat on their site one weekend. Here's one entry:

June 16th 2005 5:06 am I just love messing with their heads. Last night I hid in some tall grass so that when they tried to put me in, they couldn't see me right away. Then, just when they were giving up on me, I bounded toward them. I have them trained so that when I jump up when running they ooohh and aaahh. What a hoot! Then I grossed them out by eating my barf.

Today just before I left work, Terah called. Tux was hiding under our porch, wheezing terribly and hyperventilating. He wouldn't move at all. Which is odd, since he had been doing great the past few days. He even looked in at us watching TV a few times lately. After I got home, we managed to convince him to walk to the garage. He seemed a little better. We checked on him again at about 8:00, and he was doing pretty bad. We took him into the vet, and they decided that he had either a rare incurable viral disease, a hernia, or fluid in his chest cavity. His prognosis was not good. His lungs were functioning at only 1/8 capacity. We could attempt to treat him, but treatment would only likely save him if it was the hernia, and it would cost well over $1000. So we made the hard decision to have him put to sleep. Although I've lived around animals most of my life, this was the first time we had this decision to make. Outdoor cats usually live good lives, but rarely live long enough to become afflicted by serious disease. Cars, dogs, or coyotes usually cause a sudden end for them. As I was typing this up, I got the call that he was put to sleep. They determined that he had the viral disease, so I don't feel too bad about our choice. We have quite a few fond memories of Tux, plus some very funny video of his first experience with snow. He certainly liked to be scratched: Goodbye, Tux. We'll keep an eye on the neighbors for you.

My previous post rewritten by the inimitable Anthony Towns:

An enigmatic lady named Erinn Clark,
Was scheduled to switch coasts in the dark.
But missing her plane,
She will happily explain,
Had little effect on her lark.
A bold southern dame, she insisted;
To be on the next flight or waitlisted
(She was, as you'll see,
A New Years escapee)
And her charms just could not be resisted.
Her flight went to Tampa and then to LA,
Finally dropping her off in sweet San Jose,
Florida thus departed,
And the airline outsmarted,
Finally, now it's time for horseplay!
Let's introduce her partner in crime,
Though "Val Henson" is too hard to rhyme.
Throw 'em in a ball pit,
To their necks if they fit,
And they'll have a glorious time.
But first to a black tie affair,
To greet the New Year in a style debonair,
She was ready to skate,
But was forced to placate,
With jewelry, a shirt and a glare.
The guests were exciting and fun,
All happy and gleeful but one,
She was Lina by name,
Thought the Eve's not the same,
Without fireworks, like a day without sun.
In spite of it all, it failed to suck,
A climax as midnight eventually struck,
The year's dawn arrived,
And our heroines revived
With vegan duck which you don't have to pluck.
To summarise the rest of the story in brief:
There's being spoonfed Indian bits by the chief,
In ballpits they're tossed,
In forests they're lost,
And meanwhile namesys provides light relief.
Finally it comes time to return,
To the coast where the sunrise will burn.
But a feeling of doom,
And a small viral bloom,
Can be quite a cause for concern.
But a satisfactory note that is not,
On which to end this poetical jot,
Instead wishing this:
A year full of bliss,
May all that is good be your lot!

And people wonder why I fangirl him?

(Viral meme #1,234.) I was still in Hong Kong, packing up to leave for California due to my mom’s job being relocated. I certainly didn’t know about Debian at all at the time; I had only unsuccessfully attempted to download the Slackware installation media, but had experience with SuSE Linux 6.3 and Caldera OpenLinux 1.2. (I distinctly remember sound never working.) I recall being a lot more immediately interested in anime than anything computer-related. It was only several months later when my laptop failed to boot following an installation of some satanic Service Pack for Windows 2000 that Misha Nasledov, a classmate and Debian developer two years my senior, showed me - from his Google CD jacket - a set of Woody installation media. By evening, I was poking around the system, trying to replicate my Windows environment. A few weeks later, I remember setting the machine up to dist-upgrade to unstable! By February 2003, I had entered the NM queue…

Ian Murdock's recent piece on the whole Debian/Nexenta controversy contained what is an almost-universal misunderstanding (so common, in fact, that I held the same misunderstanding myself until fairly recently) about what the GPL actually says about linking in other software with a GPL-licenced work. Ian writes:

It seems to me the argument that linking a GPL application to a CDDL library and asserting that that somehow makes the library a derivative work of the application is, to say the least, a stretch&emdash;not to mention the fact that we're talking about libc here, a library with a highly standard interface that's been implemented any number of times and, heck, that's even older than the GPL itself. It's interpretations like this, folks, that give the GPL its reputation of being viral, and I know how much Richard Stallman hates that word.

The core misunderstanding there is that the GPL somehow claims that libraries linked into a GPL-licenced binary are derived works. Nothing in the text of the GPL states that, and a quick scan of the GPL FAQ doesn't provide any opinions of that nature, either. What the GPL does state are a few conditions which you have to abide by in order to be given permission by the copyright holder to exercise rights ordinarily held exclusively by said copyright holder. One of those is that, in order to be given permission to distribute a compiled binary, you must be able to provide source code for the binary itself, as well as all interface definition files, build scripts, and modules contained in the binary, and that all of this material must be provided under terms no more restrictive than those of the GPL. The GPL isn't trying to lay a "derived work" claim on any of those other parts. It's just saying to you, as someone who wants to distribute a binary, "here are some other things that must be OK if you want to do this". A similar clause exists with regards to patents and court judgments (section 7, for those of you playing along at home). This doesn't mean that the GPL is attempting to claim that the patents or court judgments are derived works. A licence could also say "you must delete all copies of any Microsoft product from your hard drive before duplicating this software", but that wouldn't mean that the licence is attempting to claim that all Microsoft products are derived works of the licenced software! As anyone who's looked at a typical proprietary software EULA probably already knows, a software licence can claim pretty much anything (and, apparently, thanks to the DMCA, in the US they can make it stick). The licence doesn't make the claim on the basis of derivation, it makes it because that's just what the licence claims. The GPL is no different in that respect. If you can't fulfill the licence conditions (either because you don't want to, or because -- as in the case of the clause under discussion -- the module you are including in your binary can't be licenced under terms equivalent to the GPL) then you can't do whatever it is that the licence would otherwise allow you to do. To be fair to Ian, some of the comments he made to his blog post indicate that he does understand the distinction between a claim due to derivation and one due to a simple licence term, but I thought it worth making the point crystal clear to everyone out there in the blogsphere, because it's a very common misunderstanding, and I'd hate for it to spread any further than it has already.

One of the big Debian stories of the week is that a company called Nexenta Systems has made a version of Ubuntu that’s based on OpenSolaris rather than the Linux kernel. Personally, I find the emergence of a Debian-based OpenSolaris distribution exciting, as it promises to vastly improve Solaris installation, packaging, and overall usability. Solaris is great technology with an incredible pedigree and some very compelling features (DTrace, in particular, sounds like a godsend, as I’m sure anyone who’s debugged kernel code via endless iterations of inserting printfs at strategic places would agree), not to mention that it’s now open source. However, when a Linux developer eager to have a look at all this neat new open source stuff boots up Solaris for the first time, it’s a bit of a throwback to an earlier time (not to mention the fact that apt-get is a hard habit to break..). And, so, I’m more than a little embarrassed at how certain members of the Debian community reacted to Nexenta’s work. The vitriol surprised even me, knowing as much as I know about how, uh, strongly the Debian community feels about certain issues. The issue in this case: Nexenta links GPL-licensed programs (including dpkg) with the Sun C library, which is licensed under the GPL-incompatible but still free software/open source CDDL license. Granted, Nexenta didn’t go about introducing themselves to the Debian community in the best way, and there may (may) be issues around whether or not what they are doing is permitted by the GPL, but couldn’t we at least engage them in a more constructive manner? In terms of the actual issue being discussed here, am I the only one who doesn’t get it? It seems to me the argument that linking a GPL application to a CDDL library and asserting that that somehow makes the library a derivative work of the application is, to say the least, a stretch—not to mention the fact that we’re talking about libc here, a library with a highly standard interface that’s been implemented any number of times and, heck, that’s even older than the GPL itself. It’s interpretations like this, folks, that give the GPL its reputation of being viral, and I know how much Richard Stallman hates that word. It’s one thing to ensure that actual derivative works of GPL code are themselves licensed under similar terms; it’s quite another to try to apply the same argument to code that clearly isn’t a derivative work in an attempt to spread free software at any cost. I’ve been a big GPL advocate for a long time, but that just strikes me as wrong.